-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate from junit4 to junit5 #692
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but it looks like you have some build issues to resolve.
@@ -25,7 +25,6 @@ public InvocationRequestHandler(JavaFunctionBroker broker) { | |||
|
|||
@Override | |||
String execute(InvocationRequest request, InvocationResponse.Builder response) throws Exception { | |||
WorkerLogManager.getSystemLogger().log(Level.INFO, "Java version - " + getJavaVersion()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason this log is removed? This was added to make it easier to get java version in kusto logs specifically for consumption apps as they use placeholders. I suggest we retain this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we can check the version by using log here
Line 9 in 86e4db1
WorkerLogManager.getSystemLogger().info("Loading JavaMethodExecutorImpl"); |
My concern is that put it in invocation is not a good place, when cx is having thousands rps, this can be kind of annoying and it may impact the throughput and performance when the rps is high as we need to run getJavaverion very frequently and log them to host from stdout.
So if we have a way to tell the java version, let's just save the resources as much as possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understand your concern. I feel it is better to retain it with a lower log level. This log specifically informs not only the java version but also the java path which is useful for the customer and us. Some customers had reached out asking how to get this information. The time we would save with one log is quite miniscule. Feel free to combine java version with the next log if it saves time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved the log to function load request handler as function load is far fewer than function invocation.
/azp run |
1 similar comment
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
Issue describing the changes in this PR
Migrate from junit4 to junit5
Pull request checklist
release_notes.md
Additional information
Additional PR information